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Abstract 


This paper describes a new feature implemented within the APRS system, which allows transparent 
messaging between stations on the Internet and RF sides of the network, as well as on two distant RF 
networks using the Internet as a link. 


Introduction 


In a paper presented at the Digital Communication Conference in 1997 I described the genesis of the 
Internet portion of the Automatic Position Reporting System (APRS) network. This is done with the 
APRServe software, which serves as the hub for interconnection of APRS users around the world. My 
work on APRServe has continued, and this paper will detail the Internet to RF messaging system made 
operational over the last year. 


APRS remains one of the most vibrant and exciting aspects of amateur radio. Beginning on HF and 
VHF, the system has expanded to include an Internet portion, which enables the display of a thousand or 
more APRS stations nationwide. This is accomplished with a linked backbone of servers running 
APRServe software, and Internet Gateways, or IGates, which pass data to the backbone. Until recently, 
these IGates were one way-data could get from the RF network to the Internet, but there was no way 
for information to flow in the opposite direction. 


With an addition to the APRS protocol and modifications to the Internet gateway software and the client 
programs, it is now possible to send a message from the Internet to a station on RF. Furthermore, it is 
possible to send a message between stations on two different VHF networks. This is done transparently 
to the user. 


Issues 


There are two problems that a bi-directional link between RF and the Internet could introduce into the 
APRS network. First, the volume of traffic handled by APRServe could easily overwhelm the capacity 
of the 1200-baud VHF network and the 300-baud HF network. Second, in order to ensure compliance 
with FCC regulations, the IGates must be certain that a message to be passed onto RF was originated by 
a licensed amateur. 
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Traffic Control 


The Internet has vastly greater bandwidth than the RF network, making it necessary to very carefully 
limit data coming through the gateway. In order to do this, each [Gate keeps a list of “local” stations, 
where local is defined as stations being within a certain number of hops. The optimum number of hops 
will vary based on specific local network configurations, but generally 2 or 3 is used. Only messages 
destined for “ local” stations are transmitted by an IGate. The system also does not pass messages that 
are both from and to a local station, which prevents local RF QSOs from being echoed from the Internet. 


Since the HF network consists of a single 300-baud channel that is shared between all users in the 
country, no messages are gated from the Internet to HF. 


Validation Protocol 


When initially implemented, APRServe accepted any data that was passed to it, acting like a gigantic 
party line. However, in order to comply with FCC regulations it is necessary to make certain that only 
hams can initiate a transmission. The Sprouls and I worked out a method to do this with as little impact 
to the user as possible. All APRS client programs now send a logon message, which identifies the 
callsign of the user, the version of the program, and optionally includes a validation number. Based on 
this message, APRS places each connection into one of three classes. Read only access is granted to 
those connections, which do not send a logon message. This can occur with obsolete version of the 
software and with telnet clients. Internet-only access goes to those users who have sent a logon message 
without a validation number. This class of connection allows users to send their own position reports and 
messages to internet users, but does not allow any of this data to be sent over RF. Each packet from such 
a user is identified as untrusted, and every [Gate checks to be sure a packet is trusted before sending it on 
RF. Finally, a logon message which includes a validation number which matches the callsign provides a 
user with full access. 


APRS Protocol Addition 


While a full discussion of the APRS protocol is beyond the scope of this paper, an understanding of the 
system in general is necessary to understand how the messaging works. Unlike other packet radio 
systems, APRS utilizes the unconnected format within AX.25. While unconnected packets are well 
known to be inefficient for transmission of data from one station to another, APRS uses them for the 
dissemination of data from one station to many. This is far more efficient than creating a connection 
between each APRS user within an area. 


When the APRS protocol was first designed, no provision was made for a station to forward data from 
another station (other than the standard AX.25 digipeating protocol). We added a packet format we call 
“third party” to handle this situation. It is important to note that this is not the same as the meaning as 
“Third Party” used in the FCC rules, which refers to messages from non-hams. 
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In keeping with the other APRS formats, which stress human readability, the other APRS authors and 
myself chose to simply allow the inclusion of any legal APRS packet in the form it comes out of the 
TNC while in monitor mode. For example, the following is a typical message packet as seen on the 
APRS network: 


K4HG-5>APRSM, WIDE: WU2Z >Hi Keith{1 


The new protocol simply takes this line, prefixes it with the character ‘}’, and retransmits it, appearing 
like this to a monitoring station: 


KD4DDO-2>APRS, WIDE: } K4HG-5>APRSM, WIDE: WU2Z :Hi Keith{1 


By using this simple method of encapsulation, we have enabled the retransmission of any APRS packet. 
This also turns out to be simple to parse, since it is only necessary to send the text following the ‘}’ 
recursively to the parser. In practice, we also modify the path info to be more descriptive of how the 
packet got retransmitted, so it would become: 


KD4DDO-2>APRS , WIDE: }K4HG-5>APRSM, TCPIP, KD4DDO-2* : WU2Z :Hi Keith{1 


Position Reports 


In order to avoid overloading local area RF networks, we have not allowed the [Gating of position 
reports. The thousand or more position reports seen on the Internet would overwhelm even the emptiest 
RF network. However, since a user involved in a QSO with another ham would like to see that person’s 
position on the map, an [Gate sends a position report once every 15 minutes. 


Prediction 


As is my custom I will close with a prediction of what I will be presenting at next year’s DCC. I expect 
to expand this messaging system to include email, so that a user anywhere on an APRS network will be 
able to send short email messages to anyone in the world. This should greatly increase the utility of 
APRS in disaster communications. 


Conclusions 
APRS now has of seamless integration of its RF and Internet networks. This produces a much more 
capable and robust system, and has some interesting uses in emergency communications. It is now 


possible to set up a link in a disaster area using APRS, and provide Internet messaging to all users within 
that area. 
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